This invention relates to processors that have a plurality of application programs installed thereon, each of which has its own internally defined set of objects. The system for instance customization with application independent programming of controls functions to provide the capability for a user to change an object""s behavior within a customized instance of a document in an application program without changing the object""s identity and without impacting other users who have their own instances of the object, while also providing both a consistent programming model and functionality for these objects.
It is a problem in application programs to manage customized instances of objects and to provide a consistent programming model and functionality for the controls that are defined by a variety of application program and component vendors, as well as by individual users. This problem is especially relevant in an office suite type of environment on a personal computer, where each application program in the office suite can embed objects into an extended object, which is implemented in the application program, to modify the properties, methods and events of the embedded objects. This creation of customized objects by embedding objects in the application program causes difficulty in maintaining consistency of reference when multiple users concurrently access the object and make changes to the object. This is especially problematic when the reference to the object spans multiple application programs.
As an illustration, the Microsoft Office suite of application programs comprises a Visual Basic for Applications (also termed Visual Basic) layer on which is overlaid a plurality of application programs, including: PowerPoint, Word, and Excel. Early versions of Visual Basic put code behind objects, such as forms, using a class customization model, in which the identity of the object changes during the transition from design-time to run-time. This model works for Visual Basic but does not work for the Microsoft Office environment of application programs. If Microsoft Office were to use a class customization model, then the Object Linking and Embedding (OLE) object identity of an Excel spreadsheet, Word document, etc. would change when major changes were made to the code behind the spreadsheet or document. The problem with this is that any clients who were holding onto an instance pointer of the spreadsheet or document would end up with an invalid pointer, since the underlying object that was pointed to no longer exists. A user would then have to take whatever action is necessary in order to refresh the instance pointer in every instance it is used in each application program to now point to the new instantiation of the object. Thus, an apparently benign action, such as adding a table to a Word document, can cause the interface of the Word document to change, since a property may be added to the Word document for accessing the table.
The above-noted problem is further compounded by the problem of providing a consistent programming model and functionality for the controls that that are defined by a variety of application program and component vendors, as well as individual users. This is because the application programs that are installed on a processor each have their own way of extending controls and these extensions are typically inconsistent in their implementation across the plurality of application programs. The existence of a common programming tool in an office suite environment raises users"" expectations for a common programming model for using controls. Without specific support in the programming tool, it is extremely difficult to attain such a common programming model. Each application program in the office suite would need to provide its own implementation of the controls by embedding the controls, which are provided by the underlying common programming tool, into an extended control, which is implemented in the application program, to modify the properties, methods and events of the embedded controls. Duplicating this work in all applications would result in inconsistent interfaces and operation of controls as well as increased cost of implementation due to the replication of the control programmability function across the various application programs.
The present system for instance customization with application independent programming of controls functions to place code behind documents in a multi-program environment in a manner that eliminates the object instance management problems of existing systems. The instance customization portion of the present system consists of the process whereby the behavior of an object is changed by the user without changing its identity. This is accomplished by combining a customizable object and a language engine object to form the customized instance of the object. The instance customization portion of this system is enabled by the customized object aggregating the user defined customizations into a standard object that is supplied by Visual Basic. The Visual Basic object is given a pointer to the standard part of the document object which implements the base functionality of the document.
As an example, some users of Microsoft Office application programs implement customized objects by using the Visual Basic layer directly, while many users use Visual Basic indirectly through the wizards or tools that are provided in the application programs. An instance-based programming model of objects is therefore easier for these users to understand since this is the paradigm implemented in the indirect case. For example, a user places a control on a document and writes event handling code for it. The programming model that the user sees is like Visual Basic, in that the control is accessible as a property on the control container. The system for instance customization with application independent programming of controls enables clients to hold a pointer to the document object and the user programmed control, without it becoming invalidated. Another example is where an Excel workbook is embedded in a Visio drawing. A user places a button on the document and writes event handling code for the button. Instance customization is required for this scenario because the embedding protocol assumes that the identity of an embedding is constant. This protocol and others that make similar assumptions cannot be changed because they are an integral part of the application programs. All containers of the object would therefore have to use the new protocol. In addition, all containees of the object, such as controls, would have to use the new protocol since it is possible for a containee to obtain a pointer to its container. The only possible way out of this would be to say that the object being customized by the user has a different identity from the embedded object. In other words, there are two parallel worldsxe2x80x94one for internal consumption and one for external consumption, which is an unacceptable limitation.
The present system for instance customization with application independent programming of controls also functions to provide a common programming model for a set of controls used in a plurality of application programs, such as those typically included in an office suite, installed on a processor, while also enabling customization of these controls for each application program. This is accomplished by producing an interface in an underlying common programming tool which enables a host application program to augment the properties, methods and events provided by the underlying controls by adding xe2x80x9cextenderxe2x80x9d properties, methods and in a consistent manner. The user can thus use a control in a variety of application programs, and have both a consistent experience as well as a customized experiencexe2x80x94xe2x80x9cconsistentxe2x80x9d in the sense that the functionality that is unique to the control is the same from application to application, and xe2x80x9ccustomizedxe2x80x9d in the sense that behavior that is unique to the control container is different from application program to application program. All of this is accomplished without having to replicate the underlying control programmability function on which the customization is based. The host application developer creates an extender file to add and/or modify the standard properties, methods and events of a control. The resulting extender file is later used to produce an extended control for use in this application program. The system for instance customization with application independent programming of controls merges, at run time, the standard control and the extender file to create the customized control. This enables application programs to create and use customized controls without having to replicate existing control programmability functions and also enables consistency of control implementation.
The customization of the control is created when the user takes actions that make it clear that they would like to use a specific control in a specific application program. This application program calls the controls interface of the Visual Basic layer which produces a type library entry to describe the properties, methods and events of the extended control that the user has created. This application program also maintains a type description extender library wherein an extender is an object which implements the extender properties and methods supplied by the application program. These properties and methods are typically specific to the application program. In the use of visual controls, for example, it is common for different application programs to present different mechanisms for positioning the visual controls. In a word processor, for instance, it might be useful to position controls relative to text characters. In a spreadsheet, it might be useful to position controls relative to cells in the spreadsheet. In other application programs it may be most appropriate to position controls using a two-dimensional coordinate system. Each application program may use the extender mechanism to provide its own, application program specific, properties and methods. In the case of control positioning in a two-dimensional coordinate system, this could mean providing Top and Left properties, for example. A pointer to the extender entry is returned from the application program to the Visual Basic controls interface as an output parameter to link the standard control in the Visual Basic layer and its customization definition as maintained in the application program. At run time, the system for instance customization with application independent programming of controls operates on the type definitions of extenders maintained in the application program""s standard library to implement the set of customized controls.